CRC is a well-known, conventional technique for finding data transmission errors. Typically, CRC is performed “on-the-fly” by hardware or logic circuitry, usually on serial data received in a device or system. Cyclic redundancy code (a result of a CRC determination) is typically generated at the data source, and is typically included in the header of a data packet or frame.
As shown in FIG. 1, a typical network data packet 10 comprises a plurality of words 12a-12n. The first word 12a generally includes header 14 and data 16. Words 12a-12n generally have a fixed length (e.g., 2n bits, where 4≦n≦7; typically, n=5). Header 14, on the other hand, may have a fixed length or a variable length, depending on the network and/or system. The header is not data, and for this and other reasons, it is not included in a CRC determination. Where header 14 has a length greater than the fixed length of words 12a-12n, the CRC is not calculated on words that contain only header information. Rather, the CRC calculation starts from the first word that contains some data.
Conventionally, the need to exclude header 14 from a CRC determination resulted in at least two sets of CRC hardware in a device or system configured to perform CRC determinations on incoming data. One set of CRC hardware operated on fixed length data words, and another set of CRC hardware operated on data words having a length less than the fixed length. In systems where the header may have a variable length, there are often a number of additional sets of CRC determining hardware equal to the number of possible lengths of the header.
An example of a simple version 100 of such a CRC architecture is shown in FIG. 2. Serial data is received by receiver 110 and is transferred to a logic/processing block 120 that detects the header 14 and removes it from the data stream. (Other functional circuit blocks of architecture 100 are not shown for purposes of clarity in explaining the background.) The output of block 120 is input into a 1:2 demultiplexer (or switch) 125, which selects an output 135 or 145 depending on the state of control signal CONTROL. The state of control signal CONTROL is determined by the presence or absence of the header 14 in words 12a-12n. When block 120 detects header 14 in word 12a, the serial data is output on bus 135 to CRC block 130, which (at best) is configured to process a fixed-length, 2n-2m bit quantity of data, and which may be configured as a plurality of CRC blocks, successively configured to process fixed-length, 2n-1, 2n-2 and so on down to 20 bit quantities of data. Otherwise, the serial data is output on bus 145 to CRC block 140, which is configured to process a fixed-length, 2n bit quantity of data.
This approach is highly inefficient in terms of chip area. A significant amount of chip real estate is dedicated to circuitry that is used infrequently or, in some variable-length header cases, not at all. Such architectures also unnecessarily consume power to keep all of the CRC circuitry active, even when it is not in use. In many cases, some bus lengths to and from second, third and/or further CRC blocks are relatively long, and thus consume incrementally greater power when transmitting data, in comparison with the main (e.g., 2n bit) CRC block. In some implementations, valuable processing cycles are used to determine the header length prior to CRC determination, thus rendering such approaches inefficient in terms of operational processing speed as well.
Furthermore, CRC block 130 also receives and processes a “First Vector” having a predetermined value. Typically, the “First Vector” has a bit length equal to the width of the CRC processing block 130 (in the case of FIG. 2, 2n-2m bits) and is a series of all “ones” in digital or binary logic (e.g., 1111 . . . 1). The “First Vector” is typically used to begin a CRC calculation, as it has a known effect on the calculation (e.g., it gives a known result) and is typically a disallowed data pattern. Of course, the same “First Vector” is also used to begin calculation of the CRC transmitted with the data packet.
A need therefore exists to maximize the operational efficiency and the functional circuit area efficiency of CRC circuitry to keep up with ever-increasing demands for increased network speeds, smaller chip and board sizes and reduced power consumption.